Use Case層
独立したコアレイヤーパターンのUse CaseはDDDでいうApplication Serviceにみえるkadoyau.icon
kadoyau.iconがよくわかっていないこと
Domain ServiceとUse Caseの切り分け
domain services hold domain logic whereas application services don’t.
↑はコード付きのわかりやすい記事なので読んだメモ
ドメイン知識はドメインが持つ
Domain ServiceとDomain Entityがあるが、Entityのisolationが失われるロジックはEntityにもたせられない
例：外部サービスで何かを判定してその結果を使うドメイン固有の処理がある場合
注：Domain Service上ではもちろん外部サービスをそのままつかってはいけない。インタフェースをきるkadoyau.icon
これはドメインサービスを使う
Use Caseはドメインのメソッドを呼び出して使っていくだけで、ドメイン知識をもってはいけない
「ドメイン知識」が何を指すのかが曖昧
「ドメイン知識を手順通りに呼ぶ」こともドメイン知識と言えそう。そういう意味ではUse Caseはドメインを表現している
こういう意味でのドメインは意味していない
Domain Serviceにわたすために、値をバリデーションはすることがある
だけど、Domain Serviceは（理想的には）不適な値が入ったら例外を投げたりするようにつくられているので、万が一バリデーションが漏れても不整合は起きない
ユースケース固有のロジックは持ってもいいはず
名前は機能（ストーリー）を表すとかになる？
例
一般ユーザはXできるとY
APIのControllerではバリデーションを行い、後の責務はUse Caseに移譲する
GraphQLならUse Caseを使って要素を解決するResolver現れる？
バッチでXの情報をYに送る
この場合バッチでは引数のバリデーションを行い、後の責務はUse Caseに移譲する